fix: recognise a read whose verb is at the end of the name - #585

…n it

mureo's tools put the verb LAST (google_ads_campaigns_list); the shared
read vocabulary matched a verb FIRST only (list_campaigns, the bridged
convention). Every native read therefore reached the rollback planner as
a write with no reversal hint, so a batch containing one showed the
operator a read among the items they "cannot revert" and reported
partial coverage for a change set that was in fact fully revertible.

The fix adds a SECOND predicate, reads_as_a_report_only_action, used by
the rollback planner alone. is_read_only_tool_name is unchanged.

That split is the change, not a detail of it. The first attempt at this
loosened the shared predicate, and a review showed why that is unsafe:
it has three other callers and every one decides something about PLUGIN
tools, whose names mureo does not choose --

  mcp.server._register_plugin_pattern_fallbacks  skips the guardrail
      money pattern-scan for a name that reads as a read (a DENIAL);
  mcp.plugin_semantics.derive_semantics          decides whether a call
      is promoted into action_log at all (#517);
  policy.learning_reset                          decides whether a
      change can restart a learning period.

Widening the shared rule widens all three at once. The guard against
that was a hand-written verb list, and the review defeated it by taking
a real installed naming family and swapping the verb:
yahoo_ads_patch_placement_url_list, ..._cancel_..., ..._duplicate_...,
..._attach_... each read as a read and would each have lost their money
scan. No hardcoded vocabulary can be complete for names mureo does not
control, so those three keep the strict rule and a test pins that they
do -- including for those very names.

The trailing reading still refuses a segment carrying a write verb,
because this surface has its own honesty to keep: a plugin mutation
misread here would hide a real gap inside a batch claiming full
coverage. That is a smaller harm than losing a money guardrail, which is
why the guarded reading is acceptable here and nowhere else.

The vocabulary is single-sourced from
mureo.byod._client_common._MUTATION_PREFIXES, which AGENTS.md calls
authoritative, rather than hand-maintained a second time -- the first
attempt's list was missing patch, publish, attach, detach, cancel and
duplicate, all of which that vocabulary already knew.

Also corrects the module docstring, which claimed two consumers of this
vocabulary when there are four; derive_semantics (#517) and
learning_reset were never listed.

Two tests changed premise rather than being deleted, both having pinned
the defect on purpose. The KNOWN DEFECT test in
test_batch_revertible_unit.py flips as its own docstring predicted, and
the batch now reports FULL coverage, which is the operator-visible
point. test_rollback.py's "native names are unchanged" splits into a
native write still being a write, a native read now being read-only, and
a write verb still beating a trailing read verb -- the last parametrized
over all thirteen real mutations plus the eight adversarial names the
review found, so a vocabulary gap fails here rather than in production.

…ow-up)

A re-review defeated the guard with campaign_del_list, budget_rm_check
and a fullwidth ｄｅｌ_list, and showed the consequence end to end: a
batch holding yahoo_ads_placement_url_del_list -- a DELETE, with no
reversible_params, which is the normal state for a delete -- reported
BatchCoverage.FULL while classifying the delete as "nothing to revert".
A hidden gap is exactly what the batch report exists to prevent.

The vocabulary knew `delete` but not `del`, and compared strings without
normalizing, so a fullwidth spelling was a different word. Adds the
abbreviations and blunt synonyms, and NFKC-normalizes before matching.

This does not make the vocabulary complete and the docstring says so: a
verb written in another script is not reachable from a list of English
words. That incompleteness is the reason the money scan is guarded by
the STRICT matcher rather than this one, which is the design this PR
argues for -- so the honest note belongs next to the guard, not in a
commit message.

Also from the same review:

- plugin_semantics and learning_reset, the two strict-matcher consumers
  with no pin of their own, now each fail if pointed at the loose
  matcher. Mutation-tested: swapping the predicate previously left all
  89 of their tests green.
- server.py's docstring claimed the guardrail gate used "the same list
  and matcher the rollback planner uses". Since the split that is false
  and, worse, reads as an invitation to unify them again. Corrected
  there and in test_mcp_plugin_semantics.py, both pointing at the
  argument for keeping them apart.

Left alone deliberately: server.py:452 lets a read-shaped NAME override
a plugin's explicit readOnlyHint=False, so a plugin that correctly
declares "I mutate" can still lose its guardrail. Pre-existing, outside
this diff, and tracked separately -- a declaration should beat a guess,
but fixing it means touching ToolSemantics' precedence and belongs in
its own change.